With the increase in electronic commerce (E-C), there has been a corresponding increase in use of digitally signed documents. For example, if Barbara lends Al a sum of money, and Al digitally signs a promissory note stating that he owes Barbara that sum of money, it is in Barbara's interest that Al's digital signature is sufficient to convince a third party or parties that Al owes Barbara the stated sum. However, a dispute regarding whether Al owes Barbara any money may arise after an issuing certificate authority (CA) has revoked Al's digital signature, or more particularly public-key certificate.
A public-key certificate is a data structure having a data portion and a signature portion. Conventionally, the data portion contains text of a public key and a string of data identifying a party associated with the public key. Conventionally, the signature portion comprises a digital signature of a CA over the data portion to bind such a party's identity to such a public key.
Therefore, it would be desirable to have measures for preserving the ability to establish that a digitally signed document was digitally signed before revocation of an associated public-key certificate. Others have suggested use of a public directory to store public key information. The directory is updated by an issuing CA on a regular basis, such as daily. Content of the directory is protected with a CA's signature and also by time stamping. Thus, someone trying to prove authenticity as described above could download data from the directory to establish such authenticity. Thus, continuing our example, Barbara may check that Al's public-key certificate has not expired and is not included in a list of revoked certificates. Moreover, Barbara may check to determine if the digital signature was formed at a time when Al's public-key certificate was considered valid. Such a public directory may be maintained by a disinterested third party. However, this approach has some shortcomings, some of which are if a private key is suspected of being compromised, it is not possible to revoke a certificate until a next update of the public directory is issued. Thus, in our example, a third party using Al's private key may be signing documents as opposed to Al himself, and Al may not be able to curtail such invalid use until the public directory was updated. Another shortcoming of this approach is that as the number of certificates escalates, such a public directory may become impractically large.
Another approach suggested by others is to use an intermediary that, having received a request containing a public-key certificate, replies with a validity confirmation. Such an intermediary would sign such a validity confirmation with a private key. An example of such an on-line notary protocol 20 is shown in the flow diagram of FIG. 1.
In FIG. 1, CA 10 issues certificate 12 to sender 11. Message, m, 13 is signed with a private key 21 of sender 11. Certificate 12 and signed message 14 are provided to target recipient 15. Target recipient 15 in turn provides certificate 12 and signed message 14 to confirming entity 16. Confirming entity 16 validates certificate 12. Validation or confirmation comprises verifying creation of a signed message, SigS(m), by sender, S, 11 before a corresponding certificate, CertS, was revoked, lapsed or otherwise no longer valid.
Confirming entity 16 receives confirmation information 17 for validating certificates 12 from CA 10, such confirmation information may include a list of all active certificates having association with respective entities issued them. Thus, confirming entity 11 determines whether certificate 12 is valid. Notably, CA 10 and confirming entity 16 may be one in the same entity. Other information which CA 10 may provide confirming entity 16 may include a validity period of a public-key certificate, a serial number or key identifier identifying the certificate or public key, information about a subject entity issued the public-key certificate, among other types of information.
Confirming entity 16 provides a validation statement for certificate 12 and signed message 14, collectively referred to as status 23, to target recipient 15. Status 23 is digitally signed, SigN(statusS), with private key 19 of confirming entity 16, and signed status 24 is provided to target recipient 15 along with status 23. Accordingly, proof is provided that message 13 was signed before confirming entity 16 signed status 23. Thus, a third party may check that: (i) signed message 14 is verifiable using a public key in certificate 12; (ii) certificate 12 is signed by CA 10; (iii) status 23 confirms validity of certificate 12; (iv) status 23 comprises signed message 14; and (v) status 23 is signed by confirming entity 16. With respect to item (v), a signature is created by confirming entity 16 of status 23 for each request by a target recipient 15. In other words, a signed reply is provided for each request on a one-to-one bases. Therefore, an informational bottleneck may result when supporting a plurality of requests for confirming signatures.
Accordingly, it would be desirable to provide for validation of a digital signature that is scalable.